Security analysts and researchers require vulnerability and defense information to advance security understanding and make decisions on applying security controls to computer system platforms and software. A number of libraries, checklists, and systems have been developed to attempt to address this need.
The National Vulnerability Database (NVD) is the U.S. government repository of standards based vulnerability management data which is compiled using the Security Content Automation Protocol (SCAP). SCAP is a method for using specific standards to enable automated vulnerability management, measurement, and policy compliance evaluation. Currently SCAP is in its second version which draws information from a number of other existing libraries including: CVE® (Common Vulnerability Exposure), CCE (Common Configuration Enumeration), CPE (Common Platform Enumeration), CVSS (Common Vulnerability Scoring System), XCCDF (The Extensible Configuration Checklist Description Format) and OVAL (Open Vulnerability Assessment Language).
The NVD includes a compilation of security checklists, security related software flaws, misconfigurations, product names, and impact metrics. This information is typically discontiguous, voluminous and requires extensive effort to search and correlate with other security information types or references. The chief problem is that each of the above vulnerability libraries focuses on a different aspect of defining the vulnerability or targeted system.
The CVE library is a public listing of known computer vulnerabilities which are given a rough description and assigned a unique identifier code to identify and categorize the vulnerability.
The CVSS score is an open industry standard for assessing the severity of a vulnerability to a computer system. The CVSS system assesses the vulnerability on a number of factors related to how the vulnerability operates in order to arrive at a generalized score of how severe a threat the vulnerability represents.
CPE is a structured naming scheme for IT systems, platforms, and packages. The CPE name can be used as a standardized source of information for enforcing IT management policies across a number of systems or devices.
CCE assigns unique entries to configuration guidance statements and configuration controls to improve workflow by facilitating fast and accurate correlation of known configuration issues.
XCCDF is a markup language that defines a set of rules for encoding documents in a format which is both human and machine-readable, in this case specifying security checklists, benchmarks and configuration documentation.
OVAL is a community standard to promote open and publicly available security content, and to standardize the transfer of this information across the entire spectrum of security tools and services. OVAL language standardizes the three main steps of the assessment process: representing configuration information of systems for testing; analyzing the system for the presence of the specified machine state (vulnerability, configuration, patch state, etc.); and reporting the results of this assessment.
FDCC (Federal Desktop Core Configuration) is a checklist for mandatory configuration settings on desktop and laptop computers owned by the United States government. The goal of FDCC compliance is to establish baseline security parameters and facilitate administrative tasks such as patch management.
CAPEC (Common Attack Pattern Enumeration and Classification) is to provide a publicly available catalog of common attack patterns classified in an intuitive manner, along with a comprehensive schema for describing related attacks and sharing information about them
CWE (Common Weakness Enumeration) provides a unified, measurable set of software weaknesses that enables a more effective discussion, description, selection, and use of software security tools and services that can find these weaknesses in source code and operational systems as well as better understanding and management of software weaknesses related to architecture and design
At present, a combination of the various SCAP references listed above are used to identify vulnerabilities and exposures and subscribe severity levels to assist analysts, researchers, developers, testers, and educators in making informed risk decisions. However, none of the above reference sources extensively incorporate third party vendor and technology community reference information in sufficient detail to enable an identification, prevention, or detection of vulnerabilities, as well as provide for implementation of appropriate preventive and reactive response controls. This third party information can be taken into account in combination with SCAP information sources to better inform the risk decision making process. Additional reference information includes, but is not limited to: endpoint protection, network intrusion detection, forensic indicators of compromise, compliance standards, security patches and fixes, system vulnerability assessments, exploitation techniques, and security configuration guides. An additional problem in incorporating information from these additional references sources is that these information sources may not be compatibly formatted according to an easy or common language, such as XCCDF.
As shown in FIG. 1, the central reference point for many of these different vulnerability and exposure information sources is the CVE library. In most cases these various information sources do not reference each other, or if they do, they only reference a limited set of the other available sources. In addition, methods of gathering and formatting this additional security reference information and combining it with the automated SCAP information is manual, unreliable and unstructured. Aggregating and correlating these various information sources to determine actionable risk decisions is laborious and prone to error. Further, the CVE library only reports a base risk score, determined by CVSS, in association with the identified CVE entry. This base score does not take into account other factors that could be used to understand the actual risk to a specific computer system. For example available patches vs zero-day not available patches, anti-malware detection signatures vs unavailable signatures, current ongoing global exploits vs exploits not yet seen. Further, the CVSS risk score does not factor in the use of announced third party compensating controls when assessing the likelihood of compromise. This lack of broader visibility from just CVE announcements obfuscates the true risk scoring for disclosed vulnerabilities and exploits.
The goal of the NVD is to enable the automation of vulnerability management, security measurement, and compliance for users. The NVD is publicly available and is formatted in a human and machine readable data display format known as XML. The security related software flaws contained within the NVD are represented within an XML document which is updated every two hours. Each of the vulnerabilities in the XML file includes a description and associated reference links from the CVE dictionary feed, as well as a CVSS score, vulnerable product configurations, and weakness categorization. The CVE unique vulnerability identifier is the reference point for any publicly disclosed vulnerability contained in the NVD XML. The NVD XML content is not exhaustive and does not contain additional detailed exposure information, their corresponding preventive, detection and response information. It requires its audience to obtain this information from third party sources.
The NVD XML vulnerability feed is organized by the first four digits of the CVE unique identifier “CVE-xxxx-xxxx”. When referenced, this unique identifier serves only to identify the NVD entry for the vulnerability. As such, the unique identifier does not include or indicate the presence of any of the further information related to the additional corresponding preventive, detective and responsive information already gathered in the NVD system. As such, in order to determine the overall risk of the vulnerability to a given platform, a user must open the NVD entry and assess the third-party reference information manually.
In light of the shortcomings of the present systems and methods it is desirable to provide systems and methods which automatically compile all vulnerability and exposure information for computer platforms and software, including their corresponding prevention, detection, and response information into a single database. Further, it is advantageous for the systems and methods to output the information in simple format structure to accommodate automatic usage and review. Further, it is desirable to provide the information in a database in a form that can be easily correlated to display multilevel relationships between the vulnerability and the recorded prevention, detection, and response information. Finally, it is desirable for the vulnerability entries to be classified in a manner that readily distinguishes and identifies the elements of the vulnerability information.